Exploring State - LayerX Web Frontend Night
https://gyazo.com/ae6fe558aa57da389c021033aabcfe2d
状態が中心にくる
本質的な複雑さは減らせない、移動しかできない
どこに移動するか？
状態から別の状態を計算（変換ロジック）
https://gyazo.com/fef0b0c57e30aa908c1a31a9ba48ba40
$ VirtualDOM=f(props,hooks1,hooks2,...)
onChange={e=>setState(e.target.event)}
便利
https://gyazo.com/76859835a918c52127d6d56d3e587662
現在の状態や1つ前のtransform()が返したdiffを引数で受け取る
設定はtransformを作る時に引数として受ける
分解でき、テストでき、いくつでも組み合わせられる
複雑さは何に起因するか
データ構造が巨大
更新ロジックが複雑
などなど
ざっくり分類する
UI = f(State)
stateが必ず決まればUIも決まる（一意）
カスタムフックだとReactに依存してしまう
Stateをそのまま返していないから外部からアクセスできない
内部で呼ばれた関数自体は純粋ではない
更新ロジック
今のViewModelから新しいViewModelへと遷移するようにする
参照ロジック
読みやすいデータで欲しい
バックエンドのデータベース正規化モデルとAPIレスポンスのデータ型が一致しないケースと酷似
ライブラリで解決できる
例：外貨対応の金額入力
通貨指定して金額入力する
日本円換算の金額で設定された上限バリデーションがある
Jotai: なるべく状態ではなく値に扱うようにする Stateは書き込みが可能
書き込みを正しく扱う
状態は減らしたいようにする
Derived AtomはPromiseも返せる（そうじゃないこともできる）
async sometimesパターン
ユーザーが直接編集する状態と別の値から決まる値は分ける
その値がどこから来たのかを書き込む場所を減らすようにする
ユーザーからの入力を適切に書き込むようにする
単なる状態とで別に管理するようにする